Contact CREATE Request

Function

This request is used for creating a new Contact.

Requirements

The Contact must not yet exist.

Verification

Verification information is created for a contact of the PERSON or ORG type.
The provision of verification information is optional.
The provision of a telephone number is mandatory.

Request Parameters

A Contact CREATE request is composed of the "Contact" data object fields and some other parameters, which are described below:

K/V Keyword	XML Namespace and Element	Occurrence min - max	Type / Length	Value Range	Description
Action	contact:create	1	enumeration	create-erule	request type
Version	-	1	enumeration	version-erule	This is the version. The keyword is only relevant for requests in the key/value format.
CtId	ctid	0 - 1	token 3 - 64	Any visible Unicode character (according to Unicode version 3.1)	This is the unique transaction ID which is issued by the client.

Common Mistakes

The Contact handle stated in the request already exists, see error messages related to Contact requests.

Beispiele

Example requests for PERSON or ORG

Copy

Response K/V Contact CREATE

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Action: CREATE
Version: 5.0
Handle: DENIC-1000002-MAX
Type: Person
Name: Max Mustermann
Address: Business Services
Address: Theodor-Stern-Kai 1
Address: The maximum number of
Address: address lines is five and
Address: one line may be 255 characters long.
PostalCode: 60596
City: Frankfurt am Main
CountryCode: DE
eMail: email-1@denic.de
eMail: email-2@denic.de
eMail: email-3@denic.de
eMail: email-4@denic.de
eMail: email-5@denic.de
eMail: email-6@denic.de
Phone: +49.6927235x290

[VerificationInformation]
VerifiedClaim: name
VerifiedClaim: address
VerificationResult: success
VerificationReference: ABC123/45GHT
VerificationTimestamp: 2023-11-11T15:36:21+02:00
VerificationEvidence: idcard
VerificationMethod: auth
TrustFramework: de_denic

[VerificationInformation]
VerifiedClaim: email
VerificationResult: failed
VerificationReference: 354546TZQ
VerificationTimestamp: 2023-10-04T12:22:19+02:00
VerificationEvidence: transaction_log
VerificationMethod: auth
TrustFramework: de_denic

Copy

Response XML Contact CREATE

1
2
3
4
<registry-request xmlns="http://registry.denic.de/global/5.0" xmlns:contact="http://registry.denic.de/contact/5.0" xmlns:verification="http://registry.denic.de/verification/5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <contact:create>
    <contact:handle>DENIC-1000002-MAX</contact:handle>
    <contact:type>PERSON</contact:type>

The structure in the XML document after PERSON is identical to the structure of a request with the RRI protocol 4.0 and can be adopted from there.

Copy

Response XML Contact CREATE

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    <verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType">
       <verification:verifiedClaims>
        <verification:claim>name</verification:claim>
        <verification:claim>address</verification:claim>
      </verification:verifiedClaims>
      <verification:verificationResult>success</verification:verificationResult>
      <verification:verificationReference>ABC123/45GHT</verification:verificationReference>
      <verification:verificationTimestamp>2023-11-11T15:36:21+00:00</verification:verificationTimestamp>
      <verification:verificationEvidence>idcard</verification:verificationEvidence>
      <verification:verificationMethod>auth</verification:verificationMethod>
      <verification:trustFramework>de_denic</verification:trustFramework>
    </verification:verificationInformation>
    <verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType">             
      <verification:verifiedClaims>
         <verification:claim>email</verification:claim>
      </verification:verifiedClaims>
      <verification:verificationResult>failed</verification:verificationResult>
      <verification:verificationReference>354546TZQ</verification:verificationReference>
      <verification:verificationTimestamp>2023-10-04T12:22:19+00:00</verification:verificationTimestamp>
      <verification:verificationEvidence>transaction_log</verification:verificationEvidence>
      <verification:verificationMethod>auth</verification:verificationMethod>
      <verification:trustFramework>de_denic</verification:trustFramework>
    </verification:verificationInformation>
  </contact:create>
  <ctid>cba-987654321</ctid>
</registry-request>

Data object for PERSON or ORG

K/V Keyword	XML Namespace and Element	Occurrence min - max	Type / Length	Value Range	Description	Policy
Handle	contact:handle	1	token 9 - 32	contact-rule	This is the unique ID of the Contact.Syntax: <RegAccId>-<MemberID >	A Contact handle must always start with the RegAccId of the administering RegAcc.
Type	contact:type	1	enumeration	role-erule	These Contact types are available: PERSON = natural person, ORG = a legal person (company, association, grouping of holders, organization etc., such as "DENIC eG")	The type of contact can be changed later. For Holder you may only use the types PERSON or ORG.
Name	contact:name	1	normalizedString 1 - 255	name-rule	This is the Contact's name.	Once set, you cannot change the keyword "name" any more.
Organisation	contact:organisation	0 - *	normalizedString 1 - 255	organisation-rule	This is the organisation which is represented by the Contact.	You may only use the types PERSON. Cannot be changed, if the domain bears a DISPUTE entry. You must always state the domain holder in the "Name:" field. The "Organization" value has no right to the domain and is not entitled to apply for an AuthInfo or a provider change or similar.
Address	contact:address	1 - *	normalizedString 1 - 255	address-rule	Street and house number of Contact	The keyword cannot be changed if the Contact is referenced as the holder of a domain which bears a DISPUTE entry.
PostalCode	contact:postalCode	1	token 1 - 20	postalcode-rule	Postal code and address of Contact	The keyword cannot be changed if the Contact is referenced as the holder of a domain which bears a DISPUTE entry.
City	contact:city	1	normalizedString 1 - 80	city-rule	Place of residence of Contact	The keyword cannot be changed if the Contact is referenced as the holder of a domain which bears a DISPUTE entry.
CountryCode	contact:countryCode	1	Enumeration 2	country-erule	Country code of the country in which the Contact's place of residence is located	You must use the country code of the ISO-3166-1 alpha-2 list ISO-3166-1 alpha-2 Liste. The keyword cannot be changed if the Contact is referenced as the holder of a domain which bears a DISPUTE entry.
Email	contact:email	1 - *	normalizedString 3 - 255	email-rule (see RFC5322 - Internet Message Format)	E-mail address of Contact	„email” always is a mandatory field and must be specified at least once for the types PERSON and ORG in Contact CREATE and Contact UPDATE requests

K/V Keyword	XML Namespace and Elements	1st Nesting	2nd Nesting	Occurrence, min – max per verification information block	Type / Length	Value Range	Description
[VerificationInformation]	<verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType"> <verification:verifiedClaims> <verification:verificationResult> <verification:verificationReference> <verification:verificationTimestamp> <verification:verificationEvidence> <verification:verificationMethod> </verification:verificationInformation>	-	-	Once per verification record	-	-	For K/V: header line that precedes the verification record
-	-	<verification:verifiedClaims> <verification:claim> </verification:verifiedClaims>	-	-	-	-	-
VerifiedClaim	-	-	<verification:claim> ... <verification:claim>	1 - 3	normalizedString / fixed length due to predefined valued	claim-rule	"claims" are data that has been verified Special features for e-mail The complete verification information block with all keywords or XML elements and values must be specified for an email, if the result of the email check was negative, in other words, the value is ‘failed’. A subsequent update with the positive value ‘success’ must also be communicated, after a fail. If the value ‘success’ was present at the start of the check, the verification information block for email can be reported.
VerificationResult	-	<verification:verificationResult> ... </verification:verificationResult>	-	1	normalizedString / fixed length due to predefined valued	result-rule	Notification of the verification result
VerificationReference	-	<verification:verificationReference> ... /verification:verificationReference>	-	1	normalizedString / ength is defined by member	reference-rule	The content is free text that makes reference to a request number or order number, etc.
VerificationTimestamp	-	<verification:verificationTimestamp> ... </verification:verificationTimestamp>	-	1	date-time	timestamp-rule	Point in time, when the verification was performed
VerificationEvidence	-	<verification:verificationEvidence> ... </verification:verificationEvidence>	-	1	normalizedString / fixed length due to predefined valued	evidence-rule	Evidence that was checked within the scope of the verification (e.g. for the value "idcard", which corresponds to identity card)
VerificationMethod	-	<verification:verificationMethod> ... </verification:verificationMethod>	-	1	normalizedString / fixed length due to predefined valued	method-rule	Method used to carry out the verification (e.g. for the value "pvr", which stands for evidencing via "video identification")
TrustFramework	-	<verification:trustFramework> ... </verification:trustFramework>	-	1	normalizedString / fixed length due to predefined valued	framework-rule	Framework used for the verification At present, only the value "de_denic" exists, others may follow later.

Data object for REQUEST

K/V Keyword	XML Namespace and Element	Occurrence min - max	Type / Length	Value Range	Description	Policy
Handle	contact:handle	1	token 9 - 32	contact-rule	This is the unique ID of the Contact.Syntax: <RegAccId>-<MemberID >	A Contact handle must always start with the RegAccId of the administering RegAcc.
Type	contact:type	1	enumeration	role-erule	REQUEST = an e-mail address or a URL in the URI-Template format.	For General Request and Abuse Contact you may only use the type REQUEST.
URI-Template	contact:uri-template	1	normalizedString 8 - 1024	Syntax as defined in RFC 6570 - URI Template	The variables Ulabel and Alabel in the URI-Template are replaced with the domain at a domain query (web-whois).	In case of a CREATE request, the content of the URI-Template is converted into a URL or e-mail as a test (For Alabel and Ulabel, a sample domain is used.) to check the syntax on correctness.

Contact CREATE Request

Beispiele

Thank You!

Thank your for your feedback.